爱奇艺数据中台负责人马金韬：数据中台建设与应用
接力技术，链接价值
本文根据马金韬老师在〖deeplus直播第233期〗线上分享演讲内容整理而成。首发于公众号dbaplus，经授权转载（文末有获取本期PPT&回放的方式，不要错过）
马金韬
爱奇艺数据中台负责人
目前主要负责爱奇艺数据中台的规划和建设，对广告业务和大数据体系都有一定的了解；
北邮本硕毕业，先后在百度、阿里巴巴、墨迹和爱奇艺等多家公司从事广告和大数据方向的工作。
本次分享主要从以下部分展开：
数据中台的产生：数据工作的痛点、数据中台的产生、中台的实质；
爱奇艺数据中台的定义：理解数据中台、数据中台的发展历程、输出和定位；
爱奇艺数据中台的建设：中台建设、Pingback体系、数仓体系、数仓平台、离线数仓架构、大数据平台、数据平台架构；
数据中台的应用场景：统一化、个性化、定制化。
一、数据中台的产生
说到数据中台的产生，我们不得不从数据工作的痛点来切入。我总结了八个方向，这八个方向可能不足以覆盖数据工作中的所有痛点，但肯定是数据工作中最痛的八个点。
使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。在一些数据的工作当中需要人员有专业的数据基础能力，这样就导致了数据人力的缺失，可能会影响业务的数据支持力度；
口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率，最终对业务决策造成严重影响；
数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。并且，由于环节过多，也带来了生产时间延迟的问题，可能直接影响到后续核心报表，推荐、模型的优化；
跨业务难度大：因为我们缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值；
接入成本高：这主要应用在一个新的业务场景下，也就是说，如果我们有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程；
投递质量低：因为说到数据的话肯定离不开投递，投递是我们用来记录用户行为的一连串的数据信息。如果投递过程缺少标准化或者流程管控的话，都会导致投递质量比较差；
获取数据难：可能在大家日常工作中会发现，我们数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值；
数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说我们需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和我们自己拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然我们耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。
基于这些数据工作的一些痛点，我们就会引入“数据中台”的概念。
数据中台的产生，在国内其实是阿里巴巴首先在2015年首先提出来的。提出这个概念指的是，我们通用能力的落地通过大中台加小前台的方式来实现。
但是，中台并不适合所有的公司。数据中台和其他中台可能适用的场景，也就是一个公司或者一个集团有多个业务并行发展且需要不断地沉淀通用能力的时候。
下面列举爱奇艺数据的中台化的转变过程：
左边是刚开始的状态。我们每一个团队都负责一个业务线的数据处理、报表开发，最终输出的数据也要提供给一些横向的团队使用，比如说推荐、运营和用户画像的工作。
但是，每个团队或者每条业务线所覆盖的数据场景可能都不一样，每个团队的能力或者标准也不一样，这样输出数据的质量或者口径就会参差不齐。最终导致在下游使用的时候，成本会急剧增加。特别是在这个业务快速发展了一段时间之后，这个问题就会越发地突现出来。
通过中台化建设，组织架构上靠一个团队去支撑，把数据的通用能力抽象出来，并且统一维护这套通用的能力。再将这一套通用的能力附加到每条业务线上，把每一条业务线或者说把每一个业务线输出的数据，做成一个标准化、流程化的数据体系，最终输出给下游方使用。下游方就是我们的业务，包括推荐、运营，都是整个公司运转起来的各个支持方向。
做完这个中台化之后，从下游应用的角度来说，它的口径和效率都得到了一个很明显的提升。
所以对于中台化建设，我们的目标就是避免烟囱式和重复建设，要实现抽象公共的通用能力，而且这个通用能力需要不断沉淀和更新，并不是一成不变的。同时，需要提供相关的标准和规范来指导用户共同打造和使用中台，因为单靠一个团队去支持所有标准化的事情是不太现实的。
在此背景下，中台团队有一项特别重要的工作就是提供标准和规范，让大家能以一个统一的标准去开展工作。这样按照标准化流程生产出来的数据或者是其他的技术能力都可以快速复用。
最终，其实我们还是希望能够打造一个数据生态的闭环，覆盖生产、处理、存储、治理、服务整个过程。
数据中台更像一种企业架构，是一套结合互联网技术和行业特性，在企业发展的不确定性中，寻找确定性，并且持续沉淀和抽象企业核心能力，最终支持企业快速、高效、低成本进行业务创新和增强的企业架构。
进一步，数据中台的实质就是抽象通用的数据能力，解决公司业务发展遇到的一些实际问题，降低数据的使用成本，通过数据促进业务的发展。
二、爱奇艺数据中台的定义
说了很多关于数据中台的概念，下面我们结合爱奇艺的数据中台来讨论下数据中台的定义。
这个图其实是一个很简略的图，但是能比较清晰地划分出后台、中台、前台的分界线。
数据后台：
我们大家平时更多用到了大数据集群，也就是说Hadoop、Spark、Flink以及其他OLAP工具。但是这些只是数据后台的一个概念，并没有做成一个标准化、通用化、门槛相对来说比较低的中台化的概念。
数据中台：
数据中台其实是一个数据即服务的产品概念，它包括了数据服务、数据平台、数据中台产生的数据以及在所有的数据工作中产生的标准和规范，这一些组成了我们所谓的数据中台。
数据前台：
数据前台就是我们实际的产品落地的具体例子，主要包括了几个大的方向：
分析体系，比如说用户分析、内容分析、业务报表等；
数据应用，比如说即席查询、可视化查询工具；
数据产品，类似于画像和推荐业务，可能都是一些数据最终形成的产品，直接面向用户服务。
所以数据中台抽象出来，就是指“平台+服务+数据+标准化”的概念，它是将数据的生产、收集、处理、存储和服务进行封装，并且面向不同层级的用户提供不同的服务形式。
在数据标准化过程中，数据中台可以防止数据重复建设，避免口径问题，提高数据的使用效率。
在我们的数据的生产使用过程中，可能会因为历史的原因，或者业务快速发展所带来的弊端，导致数据生产出来，并没有得到有效的使用或者生产出来的数据不够稳定、质量不够高。这个时候我们就需要对数据进行有效的治理，以提升数据传输的稳定性和准确性，同时提升资源的利用率。
从另外一个角度看，数据中台最终的目的是为了屏蔽数据工作的复杂性，让用户能够更方便、更高效地发现和使用数据，以此来满足快速发业务快速发展的需求。
下图是爱奇艺数据中台的一个发展历程，虽然相对粗粒度了一些，但是基本上能代表业界数据工作的一个发展历程。
2017年及以前：
2017年及以前大家的数据工作都是一个相对零散化的状态，用Hadoop client或者是其他的客户端进行数据工作的开发，并且通过脚本化对数据任务进行管理和运维。
但是数据生产更多是需求导向的，来一个需求，我们就可以做一个数据。而不是，我们根据业务的发展的方向去扩展数据的需求并且提前把扩展性做好，这样会导致数据比较零散，缺少统一的规划。而缺少这种标准化的建设过程也符合当时业务快速发展的需要。
2018年：
2018年爱奇艺开始推进平台化建设的事情，也就是数据平台的建设。
平台化的过程中，我们主要是完成了以下几项工作：
离线计算的任务的开发和运维管理；
对应的流式计算的开发和运维管理；
为了高效稳定地把外部的数据同步到我们的数据中台，或者把数据产出同步到其他的业务系统下，我们开发了自己的数据集成模块，用于实现不同存储数据之间的数据同步功能；
我们对数据进行了一些简单的管理，即数据表的创建到、维护、管理，都通过平台化的形式去进行的。
2019年：
在平台化初步建成之后，我们开始着手做一些标准化的工作。
标准化工作几乎覆盖了整个数据生命周期，从日志投递环节开始实施，针对Pingback2.0的规范，做了相应的工具来支持这个规范落地。同时结合公司业务制定了数据仓库规范，用于指导整个的建模流程，也对指标和维度体系都做了一个明确的定义和规范。
进一步，把数据的生产流程进行了流程化的管理，最终给下游提供了统一的数据接口能力。这个数据接口能力更多偏向应用层，我们通过前面一系列的数据开发工作，在平台上定义数据接口和数据服务，最终通过REST API的形式，对下游提供数据查询或接入能力。
2020年：
完成了上述的平台化和标准化工作之后，其实已经初步达到了中台化建设的要求。
前面提到的平台化和标准化更多的是给中台团队定义了一套统一的流程，让使用方按照这套流程做操作和处理。而中台化，其实是完成了一个从统一化到定制化的一个转变。也就是说，中台可以提供各种各样在不同环节的工具或者平台，业务方根据自己的需要进行灵活组装，把这种模块化的数据能力，定制化地输出到业务当中。
同时，我们开始了数据治理的体系。数据治理包括制定数据资产的定级标准、梳理整个数据链路、数据存储形式和数据使用审计等环节。所以可以认为，数据治理是一个持续性的工作，不像项目制工作有结项的节点和计划，这和平台化、标准化的事情还是有一定差异的。
还有就是我们在基于平台化、标准化的过程中，对新的业务抽象出一套通用的处理模板，帮助业务快速、自动化地完成接入，这种方式适合公司内部孵化的一些新业务快速接入我们的数据能力。
最后，是一个持续化的过程，即通用能力的不断沉淀。因为数据工作，或者其他技术类工作都是类似的，在实际的发展过程中技术和理念的升级，都会带来一些通用能力的抽象沉淀，所以这个不断沉淀的过程也是一个发展的过程。
数据中台面向不同的用户和场景，它的呈现形式是都不一样。因为中台的目的是服务业务和用户，它区别于平台一个特别关键的点就是它可以满足不同场景和不同用户，通过数据中台的模块化能力构建一套定制化的数据处理流程，以此来满足不同业务的个性化的数据解决方案。
数据中台输出形式分为以下几个：
服务：指可以提供对外信息查询、可视化查询、数据接口、元数据接口等服务形式，用户可以直接访问或者通过协议对接到自己的平台或者服务当中；
数据：指数据工作中一个核心的产出，最终以一个统一数仓的形式呈现出来。统一数仓完成一些标准化的工作，把业务都需要的一些通用逻辑进行抽象处理，避免下游使用方在使用过程中的重复处理。因为在重复的处理过程中，可能会引入不一致的口径或者维度，造成资源的浪费。而且，因为数据发展可能要经历业务的很多阶段，所以我们在做统一数仓的时候，需要把这些历史的演进过程，帮用户屏蔽掉，让大家在用数据时，不需要再去考虑历史的演进问题。而且我们在对于不同业务之间也做了一个标准化的处理，方便用户跨业务地去使用数据；
平台：更多面向数据开发人员，对整个的大数据的能力进行了平台化的封装。提供界面化的数据开发能力，并且数据任务的运维和管理更加高效，同时也会把工作中常用到的信息以更好的组织形式展现出来。除了这些能力之外，还有其他便于用户使用和加工数据的能力，比如HA、补跑数据等；
投递：数据来源中比较重要的一块。在形成了一套投递标准之后，去建立一些对应的投递工具用于进行投递管理。进一步，在测试和灰度阶段也增加了两个平台用于保证投递质量，分别是统计测试平台和灰度监测平台。在这两个阶段对质量进行监控，最终保证数据在真正投递出来之前稳定可靠且质量比较高；
标准/规范：是数据中台能力最基础的组成部分。也就是说，中台要输出标准流程和规范来让大家可以快速按照流程和规范去开展工作，而且这个流程和规范一定是方便用户接受的。如果一些标准流程过于复杂，就要尽可能地通过平台化、工具化的方式协助用户理解。
说到数据中台定位，因为数据中台和前台、后台都需要有一个明确的划分，数据中台定位提供了这种抽象通用的能力来支持前台团队在此基础之上进行定制化，最终在复用通用能力的同时，能够满足业务快速发展的个性化的需求，达到一个全局最优化的状态。
三、爱奇艺数据中台建设
下面给大家介绍一下爱奇艺数据中台的建设过程。
我们主要是从五个角度去输出中台能力，分别是服务、数据、平台、投递、标准/规范。在爱奇艺数据中台的实施过程中，我们划分出了三个大方向：
生产，也就是我们所说的投递体系；
数据，也就是统一数仓的体系，是数据的核心；
大数据平台能力：包括开发、治理、服务。
日志投递：
这部分我们输出了投递规范，进一步针对投递规范，我们需要对公司的相关员工进行培训，让大家深刻地理解投递是为了做什么，并且怎样才能达到我们对于用户的行为足够深入的分析要求。
在平台和工具这个角度，我们封装了Pingback SDK来满足不同端的投递工作，比如安卓、iPhone等；通过Pingback SDK去帮助业务实现通用化的工作。同时我们帮助投递管理的同学提供了一个管理平台，并且在数据的使用当中提供统计测试平台和灰度监测平台。
大数据平台：
我们有一线开发、对应的运维管理、实时开发对应的运维管理，以及数据治理、数据图谱、数据服务和即席查询。即席查询是我们数据服务里的一个子项，但是因为应用面比较广，就单独拎出来了。
统一数仓：
最后一块是统一数仓的能力，也就是为下游提供离线和实时的两种数仓能力。为了方便大家实现跨离线和实时混合使用的场景，需要进行标准化的工作，也就是离线输出的字段、定义、口径、格式和实时数据要尽可能一致，即实时数据向离线数据看齐。
同时，数仓在提供数据本身的能力之外，我们还要维护整个公司级别的指标体系和统一维度，让所有的数据系统平台和都会对接到统一的维度指标体系。而且，为了帮助数仓建设过程中的数据建模和统计指标的管理，我们建设了一个对应的数据平台，也是按照数据规范的标准建设，以此来支持使用方使用平台依照规范去建设数仓的流程化工作。
Pingback的体系就是投递体系，那么具体为什么要做这个事情呢？
投递工作面临的问题主要有以下几个点：
缺乏整体的规划，投递数据使用难度大。就是大家可能在使用的过程中说，在不同业务当中同样的字段不一样，或者不一样的还以同样的字段，或者在同一个业务因为时间的前后性，在一年前做的字段还有用但一年之后它就代表了另外一种含义，又或者产生了一个相同含义的另一个字段，这就造成了后续使用数据的难度特别大；
管理力度不足，后期维护成本极高。这其实也是一个双刃剑，如果管理力度过高的话，业务在使用起来就会觉得约束性比较强，效率就会有所降低。但如果管理力度不够的话，就会造成一种随用随投的过程，最终导致了历史延续性很差，维护成本极高。同时，如果没有工具和平台去统一维护和管理的话，大家会以各种形式来传递这些信息，导致沟通成本也相当高；
缺少共用的约束和校验环节，投递质量难以保证。由于没有一个统一的规范，导致后续对投递质量校验和监测的过程中，也就没有统一的标准，最终导致投递质量难以保障；
字段等定义不一致，跨业务数据打通很难。作为一个公司，不同业务线的数据在各自业务线发挥的价值要远远小于数据能跨业务向打通的这种价值。所以，当字段的这种跨业务线定义产生很大的差异，或者完全不一致的情况下，这种跨业务数据难打通造成的数据的价值流失特别严重。
下图右侧是一个简化流程，依据Pingback规范建设Pingback管理平台，同时开发了一整套的Pingback SDK。业务在使用SDK的时候，把这些用户行为投递出来并进行收集，通过ETL输出到测试统计和灰度监测这两个平台上，通过两个环节对数据质量进行校验，尽可能地把投递问题堵截在全量发布之前。
数仓体系几个要解决的痛点：
数据重复建设和资源浪费。这个资源浪费不是简简单单的存储和计算资源，人力资源的浪费可能更为明显；
维度和指标定义混乱。能描述同一个统计口径指标，名称完全不一样，或者名称完全一样，但是口径是完全不一致的，维度也会有类似的问题；
口径不统一。比如说我们在算转化率的时候，跨业务线的统一口径，或者同一个业务不同的需求下口径也不一致，导致后续的数据使用过程中，经常出现数据撞车的情况，这就需要花大量人力和精力去排查解决；
业务处理逻辑复杂。因为每一个业务都有自己特有的业务逻辑，并且在投递过程中可能会产生一些投递问题，所以需要在数据处理过程中把这些问题修复掉。但是，修复的过程如果没有一个统一的处理节点，就会造成每一处下游使用时都要做额外的处理，大大提高了业务处理的逻辑复杂度；
数据质量参差不齐。因为大家各自去构建自己的数据产出流程，数据质量参差不齐，越底层数据的质量问题对下游的影响度就越大；
数据使用的沟通成本高。在缺少规划的背景下，接收到一个或一批数据需求时，都会输出一些新的数据表或者数据产出。在后续复用的情况下，没有一个统一标准去维护和管理，或者我们在建设数据的过程中也没有统一标准，就会造成使用过程中也需要去反复地沟通和确认，才能真正找到对应的数据，而且找到的数据也不见得口径一定一致。
数仓平台主要是为了做业务建模、数据建模、物理建模、维度管理、指标管理和数仓管理。
数仓平台的特性：
数据表创建的约束性：比如我们需要对表有的命名规范要求，如果没有一个工具去管理，可能会因为大家对规范的理解不一致，最终导致落地过程中依然存在各种各样的差异性；
数据信息的可描述性：指在创建表的过程中，为了快速地满足业务，很少去添加一些相关的描述信息，导致数据缺少描述性。所以需要通过平台，要求用户在数据创建的过程中把信息描述的足够精细，方便后续的数据使用过程；
数据建模体系的完整性：指我们需要一个三步的建模过程，即业务建模后，有对应的数据建模；数据建模之后，针对这个数据建模，有不同的物理建模的形式。整体是一个流程化的工作，避免用户为了快速地满足业务需求跳过某些过程，最终导致建模的扩展性较差；
数据关系的维度与指标管理的系统性：通过提供一套统一的维度和指标管理体系来作为一个中心，对外输出统一的指标和维度，让大家在使用的过程中，可以使用这些标准化后的并且集中管理的元数据；
数据关系的可追溯性：是指通过数仓建设、建模的过程，促使我们后续数据表和字段的相互关系是有记录可查询的，也就是我们所说的数据血缘关系。
下面是数仓的简化架构，主要是体现了离线数仓部分。其中带颜色的一部分是统一数仓，其他的浅颜色的就是一些数据应用，包括数据集市和主题数仓。
最后一个大方向就是大数据平台：
我们大数据平台经历了五个阶段，第一个阶段和第二个阶段联系更加紧密：
开发：我们在第一阶段完成了整个数据开发的平台化、可视化能力，降低了开发门槛，并提升开发标准化。
运维：在开发之后，需要提升任务的管理和运维能力。通过建设运维管理模块的建设，保证用户更方便地对任务进行管理，并且对任务产出的稳定性和数据产出的时效性实现了有效的监控。
质量：在提供了数据开发和管理相关能力之后，需要进一步对数据产出进行质量校验，避免生产出的数据在未关注数据质量的情况下直接被使用，造成数据问题的快速扩散。
数据质量这一部分主要是为了及早地发现质量问题，尽可能地把问题解决在数据链路的更上游的阶段，避免造成数据的生产延迟和资源浪费。
使用：数据使用也是一个数据发现的过程。比如生产了很多数据，如何让用户看到这些数据，并将其更好地应用在业务需求当中。
针对这个痛点，我们完成数据图谱模块的发布，把各种的数据元信息进行收集、加工、管理，最终把完整的数据信息以一种更友好的形式提供出来，帮助大家快速地发现数据，进一步去了解数据元信息、快速准确地使用数据。
治理：是数据生态的最后一个环节，也是打造健康生态闭环的重要部分。有的公司可能是把治理放到比较靠前的环节，但是在一些场景下，比如说业务快速发展的过程中，治理往往是跟不上业务需求的。
所以我们采取的方式是，等业务发展到一定程度，再去补充数据治理的能力，对存量去治理，对增量去管控。治理工作的内容主要包括对数据和任务进行日常审计，然后通过数据血缘和使用情况，对数据的冗余度进行有效评估，并进行相应的优化，以减少资源和人力的浪费。同时在生产过程中，如果出现生产不稳定的情况，我们也可以快速地发现问题，进而优化整个的生产链路，提高整个数据生态的健康度。
这就是数据平台的一个大体的架构：
最底层是一个数据层，比如说我们的投递服务器的日志，包括业务的数据或者其他数据来源，通过我们的采集层和传输层达到我们的计算层。计算层的话，更多的是大数据集群服务，也包括一些任务调度能力；再上层是我们所提到的平台层，包括离线和流式任务的开发管理、机器学习平台、数仓平台，然后下面是对于整个的数据的ETL的一个平台化的处理，还有外部数据的一个同步能力的模块，称为数据集成。在拥有这些开发能力或管理能力的同时，我们还需要对投递管理、数据安全、数据质量、数据图谱做一些有效的建设，并且在整个数据体系中去做数据治理工作。最终是以即席查询、实时分析，数据服务、元数据服务多种形式对下游提供服务能力。
四、应用场景
数据中台的应用场景，其实面向不同阶段来提供不同的接入方式：
第一个阶段是统一化的形式。我们有一套通用的模板，它的优点和缺点都很明显，优点是接入起来很简单，缺点就是不够个性化和定制化，只能支持这种通用的数据能力。所以它比较适合于业务初期，能够进行快速接入，并且自动化地完成这种数据的处理和服务；
第二个阶段是个性化的能力。也就是说，我们把整个流程确定下来，业务在使用过程中可以针对某些环节做定制化的开发，拓展现存数据模块的能力来满足一些个性化需求，所以它更适用于业务的成长期的阶段；
第三个阶段是定制化的能力。定制化更多面向一些特别成熟的业务，也就是对于数据这一块的需求有多方面的、深层次的使用场景，并且通用的和个性化的架构已经不足以满足数据需求的情况下，可以采用定制化的能力。定制化能力也就是我们提供数据模块化的能力，然后业务再根据自己的需求去对应选取这些模块化能力，并进行组装和扩展，来满足自己定制化的需求。
以下是一个自动化接入流程：
新业务接入，做出一个产品，然后使用我们投递的SDK去进行投递，通过平台的工具进行投递的管理，最终数据采集、存储、监控，到统一数仓的加工，数据结果的输出，这整一个流程都是有统一的模板去执行的。比如我们常见的DAU、留存、新增、转化率、点击率，其实靠通用模板就能达到。
最终输出的形式，比如用户行为分析或者我们提供不同层级的数据产出物，像是MID层的聚合数据或者DWD层的明细数据等。用户可以通过自主查询的能力对数据进行查询和使用，同时业务线也会有自己的核心报表或者通用报表，可以通过这套自动化的流程产出，最终反哺到新业务当中。
这是一个快速，并且成本极其低的一个过程，更适用于业务的初期阶段。
以下是一个定制化的接入过程：
定制化的用户更多的可以参与到数据的整个处理过程当中。比如说生产和定制化的开发、业务基于统一数仓建设自己的数仓、关注自己的数据质量、输出数据结果、数据业务集市，最终能输出成自助查询的一些数据元。
然后，一些定制化的报表、用户行为的分析，都也可以去定制化自己的元数据服务和数据服务能力来对接到自己的平台或者服务上，这是一个相对来说比较定制化的过程。大家可以在某一个环节或者是某些环节去接入，更多地把自己的一个业务的特点应用到数据的整个处理过程当中。
Q & A
Q1：请问没有做过数据仓库，可以一步到位建设数据中台吗？
Q2：数仓到数据中台，和大数据平台到数据中台，哪种路径会更好些？
这两个方向并不冲突，数据中台更着重的是数据的通用能力输出，无论是数仓还是大数据平台都是数据中台不可或缺的重要组成部分；如果非要选择一个的话，我建议先建数仓，因为大数据平台是可以通过直接使用大数据集群完成相关数据工作的能力。
Q3：建设数据仓库的方法论是什么？主要用到什么系统？
主要是依赖Kimball的多维建模方法论，但是针对一些实体分析的场景，如用户数仓、内容数仓等等，则需要引入Anchor建模方式，这两种建模方式是目前我们主要采用的；我们目前是自建的数仓平台，是依赖自身制定的数仓规范进行建设的，主要有建模流程、模型管理、维度管理和指标管理等子模块。
Q4：数据仓库里，拉链表多吗？
目前拉链表较少，拉链表的生产和使用成本相对较高，而使用的场景又相对有限；如果确实有这方面的需求，可以考虑在特定的场景对快照表进行相应的处理，以实现拉链表所提供的能力。
Q5：请问投递怎么理解？是埋点或者订阅吗？主要涉及到哪些工作？
投递可以理解为用户行为的记录，包括用户启动APP、播放视频、浏览页面和点击内容等，可以记录用户在APP内的操作行为；主要涉及投递设计和管理，投递出的日志收集和ETL，包括用于监控投递质量的统计平台等。
Q6：请问什么是埋点呢？埋点丢失时预警有做吗？
埋点可以理解为用户行为的记录，即在用户的某种行为下会触发行为日志的投递；埋点丢失的预警可以有两个角度，一个是功能角度，即用户级别的监测，这依赖前端的投递SDK，用于记录投递失败的次数和信息；另一个是统计角度，即从相对粗的粒度进行行为统计，根据其他事件或者历史情况进行对比，确认数据是否有丢失。
Q7：数据重跑是怎样的？
数据重跑的场景可以分为几种情况，数据修复、口径变化、新增指标等；我们会通过数据平台的任务管理来创建重跑任务，指定重跑时间段、相关参数和并行度等，然后执行重跑任务，最后在数据重跑后进行数据的验证。
Q8：数据质量平台稽核任务的执行，对接的数据存储一般用哪些？关系型数据库还是Hive？
数据中台的数据主要是离线和实时两种形式，离线数据主要以Hive为载体，其中包括从关系型数据库接入的业务数据；实时数据主要以Kafka为载体；数据质量平台主要针对这两种形式的数据进行数据稽核。
Q9：在中台上如何开放目录或者地图，让业务方或者其他应用开发者快速获取所需数据？
数据中台中有数据图谱模块，以搜索和地图等形式将元数据以更为合理的形式输出，方便用户发现数据，并在平台一站式的完成数据的权限申请和使用。
Q10：数据治理是放到数据服务之后吗？数据治理主要是治理哪块？数据质量？数据标准？
数据治理是贯穿整个数据生命周期的，和数据服务没有前后关系，可以认为数据服务也是在数据治理的范畴之内；数据治理主要包括数据质量的分析、生产链路稳定性的分析、资源利用分析、数据标准化分析和使用审计等，数据治理的目的是为了保障数据稳定高质的进行生产，并推进整体的资源优化，同时防止数据的泄露等。
Q11：对于数据生命周期怎么处理？有做冷热备份吗？
数据有不同的资产等级，需要根据不同的资产等级制定TTL的设定；同时可以对数据进行垂直裁剪，将时效性要求较高的部分进行裁剪，以降低数据存储的成本；另外，为了满足对历史数据的追溯，可以将使用频率极低的数据存储到冷备，但需要考虑冷备的成本，包括恢复数据的经济成本和时间成本。
Q12：请问支持为多租户分配平台资源、工具、开发吗？
支持，这是数据平台必须的能力。
Q13：爱奇艺用到的大数据集群是开源的还是CDH？
主要是基于CDH的，并在此基础上进行了定制化的开发，包括内外部的各种补丁。
Q14：任务调度系统是自研的吗？还是用的开源的，哪个会比较好呢？
目前任务调度系统是基于oozie进行二次开发的，主要是增加了一些参数和打通其他的数据中台组件；目前主流的调度主要是oozie、airflow和azkaban等，各有优势，主要还是得看具体的使用场景和取舍，进而选择合适的调度系统。
Q15：请问下老师，大数据平台目前对外输出吗？
暂时还没有对外输出，由于每个公司的具体场景存在差异性，数据中台的体现形式也会稍有不同，不过后期可能会通过文章或者书籍的方式对外输出我们的想法和建设感受。
-- 精彩推荐--
↓点这里可回看本期直播